\documentclass{article}

%%%%%%%%%%%%%%%%%% Page Title Here
\newcommand{\TheTitle}{Code Review}
\input{header.tex}

\begin{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Actual Paper Here

\section*{Changes}

Almost all of the code was reviewed by our project manager Cody;
including the PostgresHandler, AwesomeCoreHandler (ACH),
AndroidServer, as well as the Android project itself and Trinh's
website portion. There were many changes that were suggested to all of
the code. Certain parts of the review focused on the lack of
documentation in the Android portion of the project. Specifically,
some changes that were made included adding methods to the ACH that
were requested by the people who would be using the module. A good
suggestion that was changed was to remove the overly generic
addRecord(Record r) method and replace it with overloaded methods of
specific types. Also, in the same module, the creations of the SQL
statements were moved into global variables for cleaner code and less
new connections to the database.

The website was also refactored and split up into smaller more
manageable modules, for easier access to the Javascript functions that
are really needed.  This way, we can easily look for functions when we
need to make changes to certain views (e.g. Admin View, Client View,
and Lab View). The changes to the AndroidServer and the Android
Project were made in a similar fashion. The code was refactored and
cleaned up so it was easier to read. Finally, a lot more documentation
has been added overall.

\section*{What Was Learned}

As a team we learned a lot of valuable information. We have learned
just how useful comments are to not only the coder, but also to those
reading the code.  It is a lot easier to look at code that has even a
brief description of what to expect from the code than code with
absolutely no commenting. Comments are also not useful if they are out
of date.  There were points where even though there were comments,
they were not congruent with what the actual method was doing. A
common reason for this was that once the documentation was written, it
would be forgotten about. We also learned that having a second set of
eyes allows for a new perspective. Cody was able to give very helpful
ideas on how to better organize certain modules of the code,
especially with the backend and web front end modules. While we all
started out with good intentions, as the project grew, some parts
became very bloated and Cody's review was very constructive and aided
in the process of slimming down the code.

There were some common remarks when we were asked about the system as
a whole.  One was that the entire team seems to be in agreement that
there needs to be more documentation accompanied with the code that is
produced, this will help aid in keeping the modules slim and
precise. Another remark that was expressed was that we feel the most
lacking portion of the project has been the Android part, and as such
we spent a lot of time this week improving that application.  All in
all, though, we are excited that the project is coming together as
well as it is and we are looking forward to our final, polished
product.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%% End Paper Here
\end{document}